src: let Environments on one isolate share a cleanup hook - #65777
Open
codebytere wants to merge 1 commit into
Open
src: let Environments on one isolate share a cleanup hook#65777codebytere wants to merge 1 commit into
codebytere wants to merge 1 commit into
Conversation
Collaborator
codebytere
force-pushed
the
fix/embedder-cleanup-hook-registry
branch
from
September 4, 2026 08:47
c16a038 to
61f728b
Compare
Collaborator
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #65777 +/- ##
==========================================
- Coverage 90.14% 90.13% -0.01%
==========================================
Files 769 769
Lines 261626 261640 +14
Branches 49663 49674 +11
==========================================
- Hits 235832 235826 -6
- Misses 16805 16817 +12
- Partials 8989 8997 +8
🚀 New features to boost your workflow:
|
Collaborator
The registry behind `AddEnvironmentCleanupHook()` is keyed on
{isolate, fun, arg} and asserts that every insertion is unique. Two
Environments on one isolate that register the same hook, which the
Node-API documentation allows per environment, abort the process on
the second `napi_add_env_cleanup_hook()`.
Key the registry on `arg` only and tell entries apart by Environment:
adding the same hook to one Environment twice still aborts as
documented, and removal prefers the current Environment's registration,
falling back to a matching one from another Environment when there is
no current context. Because the entry to remove after a hook has run can
no longer be found by {isolate, fun, arg} alone, `CleanupHookThunkRun()`
marks its entry as running and erases exactly that entry afterwards; a
removal of a running entry (a hook removing itself, as `~ObjectWrap()`
does) is a no-op, which keeps the use-after-free fixed by nodejs#65630 fixed.
Refs: nodejs#63985
Refs: nodejs#65630
Signed-off-by: Shelley Vohr <[email protected]>
codebytere
force-pushed
the
fix/embedder-cleanup-hook-registry
branch
from
September 4, 2026 17:19
61f728b to
df3574c
Compare
Collaborator
Collaborator
Collaborator
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two Environments that share an isolate and register the same cleanup hook abort the process on the second registration. That is a normal thing to do: the Node-API docs only forbid registering the same
(fun, arg)pair twice in one environment, addons commonly callnapi_add_env_cleanup_hook(env, hook, NULL)from every environment they are loaded into, and Electron loads addons into several Environments on Blink's isolate (subframes, same-process child windows).The process-global registry from #63985 is keyed on
{isolate, fun, arg}, leaves the Environment out of the key on purpose, and CHECKs that every insertion is unique, so the second Environment's registration trips the CHECK.The registry becomes a multimap keyed on
argwhose entries carry their Environment. Adding the same hook twice to one Environment still aborts, as documented. Removal prefers the current Environment's registration and otherwise takes the matching one from another Environment, so removal from a GC callback without a current context keeps working; it only consults the current context when the isolate passed in is the calling thread's current one.Because
{isolate, fun, arg}no longer identifies a single entry,CleanupHookThunkRun()marks its entry as running and erases exactly that entry after the hook returns. Removing a running entry (a hook removing itself, as~ObjectWrap()does) is a no-op and the hook may register itself again, which keeps the use-after-free fixed in #65630 fixed without caching the thunk's fields.Tests, in
test/cctest/test_environment.cc:EnvironmentTest.SameCleanupHookInTwoEnvironmentsOnOneIsolate: aborted before the change.EnvironmentTest.RemoveCleanupHookOfOtherEnvironmentOnSameIsolate: pins the cross-Environment fallback.EnvironmentTest.CleanupHookRemovesItselfWhileRunning: kept as a guard for the src: fix use-after-free in CleanupHookThunkRun #65630 case.test/addons,test/node-apiandtest/js-native-apipass.Refs: #63985
Refs: #65630
Disclosure: the code, tests and this description were written by Claude Code, directed and reviewed by @codebytere.